r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

This is a fairly dangerous workaround unless you really know everything going on in your process. I think it would be safe if:

1. no dynamically-loaded DLL calls fork, and
2. no call is made into a dynamically-loaded DLL in the child process until it exits or calls exec.

I think we really need to debug this in Cygwin and figure out what's going on, because it seems at this point like a "can't happen" case is happening.

OK. I've changed the PR to draft. Hope it won't take long time to figure out the cause.

The child processes of rustc seems no reason to call into the proc macros. However, the proc macro itself might call fork to execute other executables. In most cases, there's no reason for a proc macro to create another process, but rustc allows to do so.

Rustc can also load external codegen backends as dlls, which can and do spawn new processes (for example for linking), which internally does a fork. Rustc may decide to codegen the entirety of Command::spawn inside the codegen backend dll.

Yeah, that'd be bad. It seems like in most cases it'd probably use posix_spawn, and that would be ok (the fork and exec would be contained inside the cygwin dll). Still, not a safe thing to do in general.

Cannot reproduce this error in the latest master branch. Close now.